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@ Portable PCMCIA interface for a host computer. 

(57) A portable PCMCIA interface for a host com- 
puter having a system bus. In one embodiment 
the host computer is a SPARC based computer 
having an SBus and running the UNIX operating 
system. The PCMCIA interface provides a user 
application with access to a PCMCIA card. In 
this embodiment, the PCMCIA interface in- 
cludes software and hardware components. 
The software component includes a hardware- 
independent portion and a hardware-depen- 
dent portion. By implementing the software in a 
suitable high level language such as X", the 
software can be easily ported to other hardware 
platforms by merely adapting the hardware- 
dependent portion. The hardware component 
includes an ASIC coupled between the system 
bus and a couple of PCMCIA sockets. In some 
embodiments, the hardware also includes a 5 
volt to 12 volt DC-DC converter between the 
system bus and the PCMCIA sockets. 
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The present invention relates to an interface be- 
tween a host computer and a peripheral device. 

More particularly, the present invention relates to 
an interface between the host computer and a Per- 
x sonal Computer Memory Card International Associa- 
tion (PCMCIA) peripheral card. 

Figure 1A is a block diagram showing the hard- 
ware components of a conventional non x86 based 
host computer, such as a scalable processor architec- 
ture (SPARC) host computer. (SPARC® is a regis- 
tered trademark of SPARC International, Inc.) Host 
computer 10 includes a host central processor unit 
(CPU) 20, a memory bus (M-bus) 35, a host memory 
30, a host bus controller 50, a standardized host sys- 
tem bus 55 and input/output (I/O) devices such as a 
monitor/keyboard/mouse 41 and a hard disk drive 42. 
System bus 55 interconnects and provides communi- 
cation between CPU 20 and I/O devices 41, 42. In 
some host computers, system bus 55 is a SPARC 
based SBus. 

Figure 1B illustrates the software components of 
the host computer of Figure 1 A. A UNIX user applica- 
tion 31 is coupled to a UNIX operating system (O/S) 
1 30 having a kernel 32 and hardware-dependent driv- 
ers 33, and system bus 55. (UNIX® is a registered 
trademark of UNIX System Laboratories, Inc., a whol- 
ly-owned subsidiary of Novell, Inc.) System bus 55 is 
coupled to I/O devices 41 , 42. Typically, when host 
computer 10 is first initialized, UNIX O/S 130 is load- 
ed into host memory 30 and remains resident until 
computer 10 is powered down. Consequently, I/O de- 
vice drivers 33 corresponding to I/O devices 41, 42 
are loaded and user application 31 has access to I/O 
devices 41 , 42 by making the appropriate calls to ker- 
nel 32 which communicates the access via device 
drivers 33, system bus 55 to I/O devices 41, 42. 

The increase in the processing power of comput- 
ers such as host computer 10 has caused a corre- 
sponding increase in the complexity of user applica- 
tions such as application 31. As a result, there is an 
increasing need for additional memory, mass storage 
and communication devices, the most convenient 
form being an external device coupled to system bus 
55. Typically, adding external memory or mass- 
storage devices to host computer 10 involves the in- 
sertion of an adapter in the form of a printed circuit 
board (PCB) into an available system bus slot located 
inside the housing of computer 10. When inserted into 
the system bus slot, the PCB is electrically coupled to 
system bus 55 and the adapter is therefore capable 
of communicating with host CPU 20. Hence, the max- 
imum number of external devices that can be coupled 
to host computer 10 is limited by the total number of 
system bus slots available within computer 10. Fur- 
ther, a typical non-technical user is not trained to in- 
sert or remove PCBs, and a trained technician or ser- 
vice person is required to make such an upgrade or 
change. 


Meanwhile, in a different hardware arena of com- 
puters based on Intel's x86 family of microprocessors, 
such as the IBM personal computer, a PCMCIA spec- 
ification was developed to promote both compatibility 

5 and interoperability for adding external devices. (In- 
tel® is a registered trademark of Intel Corporation and 
IBM® is a registered trademark of International Busi- 
ness Machines Corporation.) Typically a PCMCIA 
adapter provides standardized PCMCIA socket(s) for 

10 plugging in PCMCIA cards (PC cards), and is control- 
led by associated interface software running on the 
host computer. Hence, it is now possible for an end 
user to easily insert and interchange a wide variety of 
external peripheral and memory devices implement- 
is ed in the PC card format into an x86-based host com- 
puter on demand. 

Initially, the x86-based PCMCIA interface was 
designed for relatively fast random access memory 
(RAM) cards and hence the specified read/write pro- 

20 toco! between the adapter and the x86-based host 
computer is similar to that necessary for a memory- 
type access operation. PC cards with memory in- 
clude RAM PC cards and hard disk drive PC cards. 
More recently, the PCMCIA specification was extend- 

25 ed to accommodate PC cards requiring I/O type data 
access protocol, such as FAX modem cards. 

Figure 2 is a block diagram showing both the soft- 
ware and hardware components of one such prior art 
x86-based host computer having a PCMCIA interface 

30 specifically designed for an x86-based computer sys- 
tem bus, such as an ISA or VESA bus. The software 
component includes user application 141, Microsoft's 
disk operating system (DOS) 142 and an x86-based 
hardware-dependent PCMCIA software driver 143. 

35 (Microsoft® is a registered trademark of Microsoft 
Corporation.) The hardware component includes an 
x86-based system bus 145 and an x86-based 
PCMCIA adapter 146 having a pair of PCMCIA sock- 
ets 147a, 147bforhousing a corresponding pair of PC 

40 cards 110, 120. Two examples of prior art integrated 
circuits (ICs) for the x86 based PCMCIA adapter are 
Intel's 82365SL PC card interface controller and Cir- 
rus Logic's CL-PD671 0/20. 

User application 141 accesses PC card 110 or 

45 1 20 by first making a standardized system call to DOS 
142. Next, DOS 142 makes the appropriate PCMCIA 
call to x86-based PCMCIA software driver 143 in or- 
der to communicate the access across x86-based 
system bus 145 to PCMCIA adapter 146. Upon receiv- 

50 ing the access request over bus 145, adapter 146 
translates the system bus signals into standardized 
PCMCIA signals for PC card 110 or 120. 

One problem associated with the conventional 
PCMCIA interface is that the PCMCIA specification 

55 was originally developed for computers based on In- 
tel's x86 family of microprocessors running operating 
systems such as DOS, MS-Windows or OS/2. (MS- 
Windows <s> is a trademark of Microsoft Corpora- 
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tion.) Consequently, the PCMCIA specification was 
optimized for software drivers which are coded in 
whole or part in an x86 assembler language which 
cannot be easily ported to non-x86-based computer 
systems. 5 

Another problem with most conventional operat- 
ing systems, such as UNIX and DOS, is that they are 
not designed to arbitrarily allow hardware devices to 
be connected and disconnected at random while the 
host computer is operating. Traditionally, at system 10 
boot time each device driver is polled once to deter- 
mine if the corresponding hardware device is present. 
If the device has been disconnected or is non-func- 
tional, the device driver is either unloaded from the 
host computer memory, or if left in the memory, the 1 5 
driver is never used. This particular conventional op- 
erating system characteristic prevents PC cards from 
being safely "hot- plugged", i.e., the practice of insert- 
ing or removing PC cards from a PCMCIA socket 
while the host computer is operating. 20 

Hence, there is a need for a portable PCMCIA in- 
terface which fully supports the software and hard- 
ware PCMCIA specification and is independent of the 
host computer's bus architecture, processor or oper- 
ating system. Such a portable PCMCIA interface will 25 
enable other host computers based on hardware ar- 
chitectures such as SPARC, and operating systems 
such as UNIX, to utilize the growing bank of standar- 
dized PC cards, white fully supporting the PCMCIA 
features such as hot-plugging. 30 

SUTO/IARY OF THE INVENTION 

The present invention provides a portable 
PCMCIA interface operational on many host comput- 35 
er architectures to couple a user application to a PC 
card. 

In one embodiment, the user application runs in 
a host computer having a host system bus. The 
PCMCIA interface includes both software and hard- 40 
ware components. The PCMCIA interface software 
includes a hardware-independent portion and a hard- 
ware-dependent portion, with a defined external in- 
terface between the user application and the hard- 
ware-independent portion. The external PCMCIA 45 
software interface provides PCMCIA Card Services 
and Socket Services to the user application in a man- 
ner transparent to the underlying hardware, e.g., the 
PC card. In addition, there is a defined internal inter- 
face between the hardware-independent and hard- so 
ware-dependent portions of the PCMCIA interface 
software, enabling the entire PCMCIA interface to be 
easily ported to other host computers by merely 
adapting the hardware-dependent portion. 

The PCMCIA interface hardware includes a 55 
PCMCIA adapter coupled to the system bus, the 
adapter having at least one PCMCIA socket for ac- 
commodating the PC card. The user application ini- 


tiates all data transfers to and from the PC card, as 
dictated by the PCMCIA specification. The host sys- 
tem bus compatible PCMCIA adapter supports 8 bit, 
16 bit and 32 bit data transfers to and from attribute 
memory space, common memory space and I/O 
space of the PC card. 

In some embodiments, the addition of power 
switching circuitry between the system bus power 
supply and PCMCIA socket(s) of the PCMCIA adapter 
enables the PC card(s) to be safely inserted in and re- 
moved from the PCMCIA socket(s) without the need 
for powering down the host computer. An optional 5 
volt to 12 volt DC-DC converter provides additional 
compatibility for PC cards requiring a 12 volt supply. 

The PCMCIA interface of the present invention 
has a number of advantages overthe prior art. By pro- 
viding a defined internal interface between the hard- 
ware-independent and hardware-dependent portions 
of the PCMCIA interface software, the specific char- 
acteristics of the system bus, the adapter and the PC 
card become transparent to the user application soft- 
ware running on the host computer. In addition, by im- 
plementing the software in a high level programming 
language, the entire PCMCIA interface software can 
be ported to other host computers having different 
operating systems and hardware architectures by 
merely adapting the hardware-dependent portion. 
Accordingly, the PCMCIA interface of the present in- 
vention provides a hardware and software solution 
which can be easily ported to other host computers. 

The present invention will now be further descri- 
bed, by way of example, with reference to the accorrv 
apanying drawings, in which:- 

Figure 1A illustrates the hardware components 
of a conventional SPARC host computer. 

Figure 1B illustrates the software components 
of the host computer of Figure 1 A. 

Figure 2 illustrates a prior art x86-based host 
computer having a PCMCIA interface. 

Figure 3A illustrates a PCMCIA interface cou- 
pled to a host computer in accordance with one em- 
bodiment of the present invention. 

Figure 3B illustrates the PCMCIA interface soft- 
ware running on the host computer of Figure 3A. 

Figure 4 is a block diagram showing the PCMCIA 
interface software in greater detail. 

Figure 5 is a flow chart illustrating an access of 
a PC card by a user application running on the host 
computer. 

Figure 6 illustrates a PCMCIA hardware adapter 
of the present invention. 

Figure 7 is an address map showing the SBus 
address space of the host computer allocated to PC 
cards. 

Figure 8 are two timing diagrams illustrating con- 
ventional PCMCIA read and write access cycles. 

Figure 9 illustrates a PC card read access of an 
attribute or common memory space. 
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Figure 10 illustrates a PC card read access of an 
attribute or common memory space with the WAIT 
feature. 

Figure 11 illustrates a PC card write access of an 
attribute or common memory space. 

Figure 12 illustrates a PC card write access of an 
attribute or common memory space with the WAIT 
feature. 

Figure 13 illustrates a PC card write access of an 
I/O space with byte sizing, but without the WAIT fea- 
ture. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

In Figure 3A, a scalable processor architecture 
(SPARC) based host computer coupled to a PCMCIA 
adapter of the present invention is shown. For more 
information on the SPARC computer architecture, 
see the SPARC Architecture Manual, Version 8, 1992, 
available from SPARC International, Menlo Park, 
California. As the operation of SPARC- based host 
computer 10 is well known, a detailed description is 
not provided herein. 

In accordance with one embodiment of the inven- 
tion, host computer 1 0 is coupled to a PCMCIA adap- 
ter 100 via system bus 55. Adapter 1 00 has a pair of 
PCMCIA sockets 107, 108 for housing a correspond- 
ing pair of PC cards 110, 120. PC cards 110, 120 are 
inserted into adapter 100 via a corresponding pair of 
68-pin connectors located within PCMCIA sockets 
107, 108. 

It should be noted that adapter 1 00 may assume 
a variety of physical configurations. For example, in 
one embodiment for a desktop computer, adapter 100 
includes an application specific integrated circuit 
(ASIC) mounted on a peripheral printed circuit board 
(PCB), with the PCB occupying a physical slot in sys- 
tem bus 55. An electrical cable interconnects the 
ASIC to PCMCIA sockets 107, 108. In another em- 
bodiment for a palm-top computer, adapter 100 in- 
cludes an ASIC which resides, together with CPU 20 
on a main PCB. An electrical cable interconnects the 
ASIC to PCMCIA sockets 107, 108 which are attach- 
ed to the palm-top computer housing. Alternatively, 
PCMCIA sockets 107, 108 are mounted together with 
the ASIC and CPU 20 on the main PCB of the desktop 
or lap top computer, thereby eliminating the need for 
an interconnecting electrical cable. Other embodi- 
ments and variations are also possible and will be ap- 
parent to one skilled in the art in view of this disclo- 
sure. 

For the purpose of describing the operation of a 
PCMCIA interface software driver running on host 
computer 10 and controlling PCMCIA adapter 100, 
reference is made mainly to PC card 110 and its as- 
sociated hardware and software drivers. Since both 
PC Cards 110, 120 are electrically and physicallyoou- 


pled to PCMCIA sockets 107, 108, respectively, the 
description of the operation of the software driver and 
adapter 100 with respect to first PC card 110 is equal- 
ly applicable to second PC card 120. 

5 In this embodiment, as illustrated by the block di- 

agram of Figure 3B, an UNIX operating system 135 
which includes UNIX kernel 32 and device drivers 33, 
also includes a PCMCIA interface software driver 34. 
A UNIX compatible user application 31 accesses PC 

w card 110 via PCMCIA interface software driver 34, 
system bus 55 and adapter 100. Software driver 34 
includes a hardware-independent portion 34a and a 
hardware-dependent portion 34b. 

Interface software driver 34 is coded in a suitable 

15 high level programming language, such as the "C" 
language, enabling source code of driver 34 to be 
easily ported to other host computer platforms by 
merely making source code changes to hardware-de- 
pendent portion 34b and recompiling driver 34. Exam- 

20 pies of other possible host computer configurations 
include the UNIX operating system on an x86 micro- 
processor based computer. Other variations and 
modifications of host computer platforms are appa- 
rent to one skilled in the art. 

25 Figure 4 is a block diagram showing PCMCIA in- 

terface software driver 34 in greater detail. Hard- 
ware-independent portion 34a includes a pair of PC 
card drivers 260, 270, a PCMCIA nexus driver 21 0, an 
event manager 230 and a Card Services layer 220. 

30 Hardware-dependent portion 34b comprises a sys- 
tem bus compatible PCMCIA adapter driver 250 for 
controlling adapter 100. By clearly defining an inter- 
nal interface 215 between hardware-independent 
nexus driver 210 and hardware-dependent system 

35 bus compatible adapter driver 250, in accordance 
with one aspect of the invention, the entire PCMCIA 
interface can advantageously be ported to different 
host computer platforms by merely adapting hard- 
ware-dependent portion 34b of interface software 

40 driver 34. 

Before user application 31 can begin accessing 
PC card 110, PCMCIA interface software driver 34 
must first be loaded into host memory 30. Loading of 
the various portions of software driver 34 is accom- 

45 plished during initialization of host computer 10. 
When PCMCIA nexus driver 210 is first loaded, nexus 
driver 21 0 searches through a list of all possible adap- 
ter drivers stored in a configuration file, and attempts 
to load each adapter driver into the configuration file. 

so For each successful load of a specific adapter driver, 
e.g., adapter driver 250, nexus driver 210 locates a 
corresponding driver apparatus structure, e.g. struc- 
ture 251 , associated with each adapter, e.g., adapter 
driver 250. Adapter driver 250 then saves a pointer to 

55 the corresponding driver apparatus structure 251 . 

Next, PCMCIA nexus driver 21 0 queries PCMCIA 
adapter driver 250 to obtain its basic adapter charac- 
teristics and adds PCMCIA sockets 107, 108 to the 
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list of available logical sockets. Nexus driver 210 then 
exports the logical socket list to Card Services layer 
220. Consequently, Card Services layer 220 has ac- 
cess to a hardware-independent software interface 
215 located between nexus driver 210 and adapter 5 
driver 250, enabling Card Services layer 220 to con- 
trol and manage the resources of adapter 100 and 
PCMCIA socket 107 in a hardware- independent man- 
ner. Nexus driver 210 also exports the same logical 
socket list to adapter driver 250 thereby establishing 10 
a one-to-one logical socket communication channel 
between Card Services layer 220 and adapter driver 
250. 

Card Services layer 220 also includes a Card In- 
formation Structure (CIS) interpreter 220a which en- 15 
ables PC card 110 to be self identifying independent 
of the host computer architecture and operating sys- 
tem, by requiring PC card 110 to maintain self- 
indentifying information in its CIS. The CIS is stored 
in an Attribute Memory space of PC card 110 and is 20 
made up of a singly-linked list of variable-length ele- 
ments called tuples. Interpreter 220a is a tuple parser 
which is responsible for processing all of the tuple in- 
formation. As such, PC card driver 260 does not need 
any tuple parsing code. 25 

In this embodiment, each tuple is one byte in 
length, with up to 256 distinct tuples stored in the CIS 
of PC card 110. When a tuple is parsed and recog- 
nized by interpreter 220a, interpreter 220a causes the 
tuple data from PC card 110 to be copied into a tuple 30 
entry in an interpreter linked list 220b. Conversely, 
when interpreter 220a does not recognize the tuple, 
a flag is set indicating that the tuple was not recog- 
nized and that tuple data from PC card 110 should not 
be copied into a tuple entry in interpreter linked list 35 
220b. Upon the successful parsing of the CIS of PC 
card 110, linked list 220b contains the configuration 
parameters of PC card 110, e.g., type of PC card, 
memory capacity and access speed. Subsequently, 
Card Services layer 220 uses linked list 220b for proc- 40 
essing card service requests from PC card driver 
260. 

In some embodiments, PCMCIA nexus driver 21 0 
does not export its private interface 215 with adapter 
driver 250 to PC card driver 260. Interface 225 be- 45 
tween Card Services layer 220 and PCMCIA nexus 
driver 210 is also private, e.g., PC card driver 260 
does not make direct calls to PCMCIA nexus driver 
210. Instead, whenever user application 31 accesses 
PC card 110, all calls to PC card driver 260 destined 50 
for PCMCIA nexus driver 210 are serviced through 
Card Services layer 220. As such, Card Services lay- 
er 220 provides PC card driver 260 a single entry 
point with a variable argument list based on the func- 
tion requested. 55 

Next, in order to support a PCMCIA specified 
event callback feature, event manager 230 is loaded 
as a separate STREAMS, enabling nexus driver 210 


to communicate PCMCIA events, such as PC card in- 
sertion/removal (hot-plugging), to user application 
31 . (A STREAMS is a UNIX full-duplex connection be- 
tween a process and a device driver). Hence, nexus 
driver 210 is provided an efficient event callback 
mechanism to user application 31, with event man- 
ager 230 observing the events and managing both 
adapter 100 and PC card 110 via adapter driver 250. 
Event manager 230 is an efficient solution because 
the number of PC cards available make it unwieldy 
and inefficient for user application 31 to poll for every 
possible PCMCIA card. More importantly, event man- 
ager 230 typically provides the sole mechanism (gen- 
erally unsupported by UNIX) for implementing the 
PCMCIA specified channel for unsolicited feedback 
to user application 31 . 

For example, when PC card 110 has been suc- 
cessfully inserted into PCMCIA socket 107, nexus 
driver 210 receives a "card insertion" event notifica- 
tion from adapter driver 250, enabling nexus driver 
21 0 to keep track of which type of PC card is present 
in socket 107. Subsequently, a corresponding PC 
card driver, e.g., driver 260, is loaded and nexus driv- 
er 210 updates the corresponding driver apparatus 
structure, e.g., structure 251, thereby forming an as- 
sociation between PCMCIA socket 107 and PC card 
110. A discussion of the PCMCIA interface hardware 
for supporting this event callback feature is included 
in a detailed hardware description of adapter 100 be- 
low. 

Once the loading and initialization of PCMCIA in- 
terface software driver 34 are completed, user appli- 
cation 31 has access to adapter 1 00 and PC card 110. 
Figure 5 is a flow chart illustrating an access of PC 
card 110 by user application 31 running on host com- 
puter 10 in accordance with one embodiment of the 
invention. 

First, user application 31 makes an external hard- 
ware-independent PCMCIA call to PC card driver 260. 
Card driver 260 responds by requesting an appropri- 
ate card service from Card Services 220. Card Ser- 
vices 220 is responsible for processing all card ser- 
vices requests from PC card driver 260 and making 
the appropriate calls into PCMCIA nexus driver 210. 
PC card driver 260 provides Card Services 220 with 
a pointer to PC card driver's device information poin- 
ter (DIP) thereby uniquely identifying PC card 110 
and providing a path to PC card driver 260's parent 
process, i.e., nexus driver 210. Card Services layer 
220 then uses the DIP to locate and to make the ap- 
propriate calls into nexus driver 210. Such calls in- 
clude adapter hardware configuration requests des- 
tined for socket services provided by adapter driver 
250. 

In response to the appropriate calls from Card 
Services layer 220, nexus driver 210 generates cor- 
responding internal hardware-independent software 
calls to PCMCIAadapter driver 250. (For additional in- 
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formation on PC Card Services, please refer to Ap- 
pendix A, which is incorporated herein.) Hardware-de- 
pendent adapter driver 250 then converts the internal 
software calls into appropriate system bus signals for 
adapter 100. Adapter 100 in turn generates the appro- 
priate PCMCIA card signals for PC card 110 located 
in PCMCIA socket 107. 

In sum, user application 31 initiates data access- 
es with PC card 110 by communicating the request in 
the form of a hardware-independent external 
PCMCIA call to PCMCIA interface software driver 34. 
In turn, software driver 34, resident on host memory 
30, receives the external PCMCIA call and causes the 
appropriate-dependent adapter specific signals to be 
asserted on system bus 55. Hence, having described 
the operation and services provided by the various 
portions of interface software driver 34 in converting 
an access request from user application 31 into the 
appropriate system bus signals, the operation of the 
PCMCIA interface hardware, i.e., adapter 1 00 and PC 
card 110 is now described in detail. 

In one embodiment as illustrated by Figure 6, 
PCMCIA adapter 100 includes an application specific 
IC (ASIC) 100a having a host bus interface buffer 
101, an adapter core logic 102, and a card interface 
buffer 103. Adapter 100 also includes a power switch 
105, a PROM 106, and a pair of PCMCIA sockets 107, 
1 08. PROM 1 06 is an open boot PROM (OBP) which 
provides standard boot ROM functionality for host 
computer 10. 

Figure 7 is an address map showing three meg- 
abytes of the system bus address space in host mem- 
ory 30 allocated to each of PC cards 110, 120, i.e., a 
six megabytes of address space is dedicated to PC 
cards 110,120. 

In this embodiment, address space 0 to FFFFFh 
and 3FFFFFh to 4FFFFFh of memory 30, are re- 
served for accessing PROM 106, and the content of 
control and status registers (CSRs) 1 02a, respective- 
ly. The PCMCIA specification also supports up to 64 
megabytes each for attribute memory, common 
memory and I/O memory space. However, in the de- 
scribed embodiment of PC card 110 only one mega- 
byte of system bus address space each is reserved 
for attribute memory, common memory and I/O ad- 
dress space. As such, address mapping is required 
for transposing the system bus address space within 
specified PCMCIA address space. The address map 
for the 6 megabyte address space of adapter 100 is 
stored in PROM 106. 

CSRs 1 02a are used to store parameters for con- 
figuring adapter 100 to operate with various type of 
PC cards. In addition, CSRs 102a also contain the ad- 
dress offset tables necessary for mapping each of the 


'Signal is active low. 


one megabyte system bus address spaces within 
each of the 64 megabyte PC card address space. 
These address offset table values can be modified by 
host computer 10 to suit a particular PC card, e.g., a 

5 FAX modem card, a RAM memory card, or a Win- 
chester disk drive card. Configuration parameters 
stored in CSRs 102a include the data access speed 
of PC card 110 which can vary a great deal depending 
on the card function, ranging from a relatively slow 

10 modem card to a relatively fast RAM card. 

Figure 8 shows two basic timing diagrams illus- 
trating conventional PCMCIA read and write access 
cycles on system bus 55 in response to read and write 
accesses of PC card 110 by user application 31. Note 

15 that data transfers are initiated by user application 31 
as defined by the PCMCIA specification Version 2.1. 
For example, in response to a read access of PC card 
110, adapter 100 asserts card address lines ADDR 
and card enable line CE* of PCMCIA socket 107. 

20 Adapter 100 then asserts the output enable signal 
OE*, indicating a read access of PC card 110 at the 
location indicated by card address lines ADDR. After 
a specific period of time (i.e., PC card read access 
time), PC card 110 drives the requested data onto 

25 card data lines DATA. Similarly, in response to a write 
access of PC card 1 10, adapter 1 00 asserts card data 
lines DATA, card address lines ADDR and card enable 
Mne CE*, followed by the assertion of card write en- 
able line WE. 

30 In accordance with one embodiment of the inven- 

tion, adapter 100 supports byte, halfword (16-bit) and 
word (32-bit) data accesses of PC card 110. Since 
PCMCIA socket 107 can only support 16-bit data 
transfers, any sizing is performed external to PC card 

35 110. Although the described embodiment of adapter 
100 does not perform any data packing -(i.e., adapter 
1 00 does not generate multiple read accesses to card 
110 in response to a single system bus read request), 
one skilled in the art will be able to extend the princi- 

40 pies of operation to other embodiments of adapter 
100 that supports data accesses of word lengths 
greater than 16-bits without the need for external siz- 
ing by host computer 10. 

In addition, when an access is initiated at an at- 

45 tribute memory space or at an I/O address space of 
card 110, card memory select iineC0_REG* is assert- 
ed low. Conversely, when an access is initiated at a 
common memory space, card memory select line 
C0_REG* is asserted high. 

so Referring to the timing diagram of Figure 9, a byte 

wide read initiated by computer 10 via adapter 100 of 
an attribute or common memory space on PC card 
110 is illustrated. First, a base address value BASE 
stored in a corresponding Window Control Register of 
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control and status register 102a and the offset ad- 
dress value on system bus address lines SB_PA are 
presented on card address lines C0_A thereby mapping 
the system bus address into a PC card address. Next, 
a card output enable line C0_CE* is asserted low. L+1 s 
clock cycles later, L being the Command_Strobe_De- 
lay value CMDDLY stored in the Window Control Reg- 
ister, a card output enable line C0_OE* (shown as C- 
0_RDCMD* in Figure 9) is asserted low. The selected 
PC card, i.e., PC card 110, then retrieves the request- w 
ed memory data byte internally and presents the data 
value onto card data lines C0_D. 

After another M+1 clock cycles, where M is a 
Command_Strobe_Length value CMDLNG stored in 
the Window Control Register, the data byte value on 15 
card data lines C0_D is latched by adapter 100 and 
card output enable line C0_RDCMD* is de-asserted. 
One clock later, card output enable tine C0_CE* is de- 
asserted. Finally, adapter 100 asserts a byte "ACK" 
on system bus line SB_ACK* for host computer 10, 20 
driving the latched data byte onto system bus data 
lines SB_DATA another clock cycle later, thereby 
completing the byte wide read cycle. 

A half word wide attribute or common memory 
read of PC card 1 1 0 is as follows. First, the BASE val- 25 
ue in the Window Control Register is applied onto 
card address lines C0_A, the offset address value on 
system bus address lines SB_PA is applied onto card 
address lines C0_A, and card enable line C0_CE* is 
asserted low. L+ 1 clock cycles later, card output en- 30 
able line C0_OE* (shown as C0_RDCMD* in Figure 
9) is asserted low. Selected PC card 110 then pres- 
ents the corresponding memory data bytes onto card 
data lines C0_D. After M+1 clock cycles, the valid 
data bytes on card data lines C0_D are latched into 35 
adapter 100 and card enable line C0_OE* (see C- 
0_RDCMD*) is then de-asserted. One clock cycle lat- 
er, card enable line C0_CE* is de-asserted. Adapter 
100 asserts a half word ACK onto system bus line 
SB_ACK* and drives the latched data byte-swapped 40 
onto system bus data lines SB_DATA, thereby com- 
pleting the halfword read cycle. 

A word wide attribute or common memory read of 
PC card 110 is similar to the halfword read access up 
to and including the assertion of the halfword ACK 45 
back to host computer 10. The halfword ACK on sys- 
tem bus 55 informs host computer 10 that the word 
read requires sizing. As such, computer 10 must ini- 
tiate another access via system bus 55 to read the 
other halfword of the desired word of data. The sec- so 
ond read cycle of the second halfword occurs in the 
same manner with the exception that the value on 
system bus address line SB_PA [1] and also card ad- 


dress line C0_A[1] are now both °1 B instead of "Of, so 
that the appropriate next halfword of data is fetched. 

As discussed earlier, the PCMCIA specification 
was originally developed for external RAM memory 
cards. However, as other slower storage mediums, 
e.g., hard disk drives, were physically shrunk to fit the 
PCMCIA form factors, it became necessary to en- 
hance the PCMCIA specification to support another 
mode of operation, i.e., accessing PC card 110 using 
a "WAIT" feature. In this embodiment the WAIT fea- 
ture enables adapter 100 to allow a slow PC card 100 
to delay responding to an access by assert a card wait 
signal CO_WAIT*, as illustrated by Figure 10. 

When host computer 10 initiates a read access to 
PC card 110 which utilizes card wait line C0_WAIT*, 
(a wait_request bit WAITREQ is enabled in the Win- - 
dow Control Register), the BASE value and the offset 
address value on system bus address lines SB_PA 
are is applied onto card address lines C0_A, and card 
enable line C0_CE* is asserted low. L+1 clock cycles 
later, card output enable line C0_OE* (shown as C- 
0_RDCMD* in Figure 10) is asserted low. 

M + N + 2 clock cycles later, N equal to a 
WaitJDelay value WAITDLY in the Window Control 
Register, adapter 100 samples card wait line C- 
0_WAIT. If card wait line C0_WAIT* is asserted PC 
card 110 requires a delay in the completion of the 
memory access. The PCMCIA specif ication permits 
card wait line C0_WAIT* to be asserted for a maxi- 
mum of 12 microseconds. Since the rising edge of 
card wait line C0_WAIT* is asynchronous with re- 
spect a system clock of host computer 10, when PC 
card 110 de-asserts card wait line C0_WAIT, adapter 
100 has to synchronize incoming card wait line C- 
0_WAIT*. 

Next, PC card 110 asserts the requested memory 
data bytes onto card data lines C0_D before de-as- 
serting card wait line C0_WAIT*. Adapter 100 latches 
the data and de-asserts card output enable line 
C0_OE* (see C0JRDCMD* of Figure 10). One clock 
cycle later, card enable line C0_CE* is de-asserted. 
Finally, adapter 100 asserts an "ACK" on system bus 
line SB_ACK* and a clock cycle later, presents the 
latched data onto system bus data lines SBJDATA. 

A non-wait byte I/O read access of PC card 110 
is similar to that of the byte read of an attribute or 
common memory described above with the exception 
that a card I/O ready line C0JORD* (shown as C- 
0_RDCMD* in Figure 10) is asserted low instead of 
card output enable line C0_OE*. Similarly, a halfword 
I/O read access begins as in the halfword read of at- 
tribute or common memory with the exception that 
card line C0JORD* (see C0_RDCMD*) is used in- 


*Signal is active low. 
'Signal is active low. 
"Signal is active low. 
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stead of card enable line C0_OE*. 

If PC card 110 is capable of performing a 16-bit 
I/O access, card 110 asserts a card l/0_is_16_bit line 
IOIS16 (not shown) low during the read access, and 
both bytes of data are presented onto card data tines 
C0_D, i.e., all 16 data bit lines are valid. Adapter 100 
then generates a half word ACK to host computer 10 via 
system bus line SB_ACK* and presents the latched data 
byte-swapped onto system bus data lines SB_DATA a 
dock cycle later. 

Conversely, if PC card 1 1 0 is only capable of byte 
sized I/O read access, card 110 does not assert card 
line IOIS1 6* low during the read access, and only the 
data byte presented on the responding 8 bits of card 
data lines C0_D are valid. Next, adapter 100 asserts 
a byte ACK to host computer 10 via system bus line 
SB_ACK" thereby indicating that the half word I/O ac- 
cess requires sizing. Host computer 10 then initiates 
another I/O access on system bus 55 to read the sec- 
ond byte in order to complete the half word I/O access. 

An I/O read of PC card 110 with the WAIT feature 
is also similar to the read access of an attribute or 
common memory with the WAIT feature, with the ex- 
ception that card I/O ready line C0JORD* (shown as 
C0_RDCMD* in Figure 10) is asserted low instead of 
card line C0_OE*. The PCMCIA specification permits 
a maximum of 12 microseconds delay between the 
beginning and end of a read access. However, PC 
card 110 can delay completion of the read access be- 
yond the 12 microseconds by using card line C- 
0_WAIT*, requiring adapter 1 00 to support split reads 
on system bus 55. Once a read is initiated by host 
computer 10 on system bus 55, a rerun ACK is assert- 
ed by adapter 100 if a time out occurs while card wait 
line C0_WAIT* is asserted by PC card 110. The split 
read access is completed during a subsequent read 
retry by host computer 1 0 on system bus 55. Next, PC 
card 110 de-asserts card wait line C0_WAIT* with the 
read data is presented system bus data lines SB_DA- 
TA. 

Conversely, if PC card 110 asserts but fails to de- 
assert card wait line C0_WAIT* within the 20 micro- 
seconds during a read access cycle, adapter 1 00 ter- 
minates the read access cycle and generates an in- 
terrupt on system bus 55. The interrupt signals to host 
computer 10 that a WAIT time-out has occurred. 

In accordance with this embodiment of the inven- 
tion, adapter 100 also supports non-WAIT byte, half- 
word and word data write accesses on PC card 110, 
as illustrated in the timing diagram of Figure 11 . Adap- 
ter 100 has a 16-bit wide data interface with system 
bus 55 and with external sizing performed by host 
computer 10 for word-size write accesses using half- 
word ACKs. As discussed above when computer 10 


'Signal is active low. 
"Signal is active low. 


initiates a write access at an attribute or common 
memory or I/O address space, card select line 
C0_REG* is asserted low. 

When a byte write of PC card 110 attribute or 

5 common memory is initiated by computer 10, the 
BASE address value and the offset address value 
from system bus address lines SB_PAare presented 
onto card address lines C0_A, the data value on sys- 
tem bus data lines SB_DATA is driven onto card data 

10 lines C0_D, and card output enable line C0_CE* is as- 
serted low. Next adapter 100 asserts a byte ACK 
thereby terminating the write cycle on system bus 55. 
L+1 clock cycles later, card write enable line C0_WE* 
(shown as C0_WRCMD* in Figure 11) is asserted low. 

15 After M+1 clock cycles, card write enable line 
CO^WE* is de-asserted low. P+1 clock cycles later, P 
equal to Recovery_delay value RECDLY, card output 
enable line C0_CE* is de-asserted. 

When a halfword (16-bits) wide write of attribute 

20 or common memory is initiated, the value of the BASE 
address value and the offset address value on system 
bus address lines SB_PA are presented on card ad- 
dress lines C0_A, the data value on system bus data 
lines SB_DATA is byte-swapped before being pre- 

25 sented onto card data lines C0_D, and card enable 
line C0_CE* is asserted low. Next, adapter 100 as- 
serts a halfword ACK on system bus line SB_ACK*, 
thereby terminating the write cycle on system bus 55. 
L+1 clock cycles later, card write enable line C0_WE* 

30 (shown as C0_WRCMD* in Figure 1 1 ) is asserted low. 
After M+1 clock cycles card, write enable line 
C0_WE* is de-asserted. Finally, P+1 clock cycles lat- 
er, card enable line C0_CE* is de-asserted. 

The sequence of events required for initiating a 

35 word sized write of Attribute/Memory is similarto that 
of a halfword write of PC card 110. The difference be- 
ing that adapter 100 asserts a halfword ACK termin- 
ating the system bus write cycle, thereby informing 
host computer 10 that sizing is required to complete 

40 the word-size write access. Computer 10 responds by 
initiating a write of the second halfword of data over 
system bus 55. 

Referring to the timing diagram of Figure 12, 
adapter 100 also supports data write accesses to at- 

45 tribute or common memory of PC card 110 using the 
WAIT feature. When a write access is initiated at PC 
card 110 which utilize card wait line C0_WAIT A , the 
BASE address value and the offset address value on 
system bus lines SB_PA are presented on card ad- 

so dress lines C0_A, the data value on system bus data 
lines SB_DATA is driven onto card data lines C0_D, 
and card enable signal C0_CE* is asserted low. Adap- 
ter 1 00 then sends an appropriate ACK, i.e., byte ACK 
for byte write and halfword ACK for halfword or word 
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write, thereby terminating the system bus write cycle. 

L+1 clock cycles later, card enable line C0_WE* 
(shown as C0_WRCMD* in Figure 12) is asserted 
low. M+N+2 clock cycles later, card wait line C- 
0_WAIT* is sampled. If card wait line CO_WAIT* is 
equal to "0", card 1 1 0 is requesting a delay in the com- 
pletion of the memory access. As discussed earlier, 
the PCMCIA specification permits a maximum wait 
period of 1 2 microseconds. When PC card 110 de-as- 
serts card wait line C0_WAIT* f adapter 100 de-as- 
serts card write enable line C0_WE* (see C- 
0_WRCMD*). P+1 clock cycles later, card enable line 
C0_CE* is de-asserted. 

In this embodiment, adapter 100 also supports 
non-WAIT I/O write accesses of PC card 1 1 0 with byte 
sizing, as illustrated by the timing diagram of Figure 
13. A byte I/O write access of PC card 110 is similar 
to that of a byte write of attribute or common memory 
with the exception that a card I/O write line C- 
0 JOWR* (shown as C0_WRCMD* in Figure 1 3) is as- 
serted instead of card write enable line C0_WE*. Sim- 
ilarly, a half I/O write accesses of PC card 110 begin 
as in the halfword write of attribute or common mem- 
ory with the exception that card I/O write line C- 
0JOWR* (see C0_WRCMD*) is asserted instead of 
card write enable line C0_WE*. 

As discussed above, PC card 110 is configured 
for I/O type operations by loading the appropriate 
Card Information Structure (CIS) into optional Con- 
figuration Registers located at the base of the 
PCMCIA common address space. The I/O access 
protocol is similar to common memory access proto- 
col except that card I/O lines C0JORD* (shown as C- 
0_RDCMD* in Figure 9) and C0JOWR* (see Figure 
13) are used for handshaking instead of card enable 
lines C0_OE* and C0_WE*, respectively (shown as 
C0_RDCMD* and C0_WRCMD* in Figures 9, 11, re- 
spectively). 

Referring again to Figure 1 3, PC card 110 asserts 
card line IOIS1 6* low (not shown) to indicate that card 
110 is also capable of executing a 16 bit wide write. 
In response, adapter 100 asserts card enable line 
C0_CE1 * low so that both bytes of data presented on 
card data lines C0_D are written into PC card 110. 

Conversely, if PC card 110 does not assert line 
IOIS16* (not shown) low during the I/O write access, 
i.e., PC card 110 is not capable of performing a 16 bit 
I/O write, only card enable line C0_CE1* is asserted 
low so that only the even byte presented on card data 
lines C0_D from system bus data lines SB_DATA is 
written into PC card 110. Adapter 1 00 then completes 
the halfword I/O write cycle by executing one more I/O 
byte write to PC card 110 as described above. This 


second byte I/O write access differs from the first 
byte write in that card address line C0_A [0] is set to 
"1° and the odd byte value from system bus data lines 
SB_DATA is presented onto card data lines C0_D. 

5 Adapter 1 00 also supports I/O write access of PC 

card 110 with the WAIT feature. Referring back to Fig- 
ure 11, the sequence of events for I/O write access 
with the WAIT feature is similar to that for write ac- 
cess of attribute or common memory with the WAIT 

10 feature, with the exception that card I/O write enable 
line C0JOWR* (shown as C0_WRCMD* in Figure 1 1 ) 
is asserted instead of card write enable line C0_WE* 
during an I/O write access. If PC card 110 asserts but 
fails to de-assert card wait line C0_WAIT* within 20 

15 microseconds, the I/O write access is terminated and 
card 1 1 0 generates a status change interrupt (SCI NT) 
to host computer 10 with PC card access time-out 
(PCTO) bits set in the Interface Status Register, indi- 
cating that a WAIT time-out has occurred. 

20 Appendix B is a detailed data sheet for one em- 
bodiment of adapter 100 and is incorporated herein. 
Appendix C are verilog files of this embodiment and 
is also incorporated herein. 

As discussed above, PCMCIA socket 107 can be 

25 configured either to operate in attribute/common 
memory mode or I/O mode depending on the capa- 
bility of PC card 110. When PCMCIA socket 107 and 
is configured for attribute/common memory mode, 
adapter 1 00 generates a card status change interrupt 

30 whenever adapter 100 detects any of the following 
events: 

PC card access time-out 

PC card write protect status change 

PC card ready- busy* status change 

35 PC card battery status change 

PC card is inserted or removed Conversely, 
when PCMCIA socket 107 is configured for I/O mode, 
adapter 1 00 generates a card status change interrupt 
whenever adapter 1 00 detects the following events: 

40 PC card access time-out 

PC card is inserted or removed 
PC card generates a status change interrupt 
The interrupts generated by adapter 100 pro- 
vides a variety of functions. For example, when PC 

45 card 110 is configured as an I/O card, PC card 110 
generates a status change interrupt to host computer 
10 by asserting a card status change line STSCHG* 
(not shown) whenever a change in card status is de- 
tected. Adapter 100 detects card status line 

so STSCHG* and in turn generates an interrupt over 
system bus 55 to computer 10. Host computer 10 
reads the Pin Replacement Register on {I/O type) PC 
card 110 to determine the source of the PC card sta- 


*Signal is active low. 
*Signal is active low. 
•Signal is active low. 
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tus change interrupt Each source of the card status 
change interrupt is individually maskable by adapter 
100 and is available on system bus interrupt request 
line SB_INT[0]. Subsequently, the card status 
change interrupt is cleared by host computer 10 by 
writing a "1" to the corresponding status change bit in 
the Interface Status Register 0. 

As discussed above, this embodiment also in- 
cludes hardware which supports PC card hot-plug- 
ging. Referring back to Figure 6, adapter 1 00 provides 
control signals to a power switch 1 05 for applying and 
removing one of two power sources Vcc, Vpp to and 
from PC card 110. Such an arrangement enables PC 
card 110 to be hot-plugged, i.e., safely connected to 
or disconnected from socket 1 07 of adapter 110, with- 
out powering down host computer 10 by continuously 
monitoring the presence and absence of PC card 110 
with respect to PCMCIA socket 107 in the following 
manner. 

When host computer 1 0 is first powered up, adap- 
ter 100 does not provide power to PCMCIA socket 
1 07. Instead, upon detecting the existence of PC card 
in socket 107 during the power-up sequence, or de- 
tecting a subsequent insertion of PC card 110 after 
the power-up sequence, a power switching circuit 1 05 
begins to provide power to PC card 110 by turning on 
the appropriate power MOSFETs of switching circuit 
105. Conversely, when adapter 100 is interrupted and 
informed of the removal of PC card 110, adapter 100 
sends the appropriate signal via Card_0_Pwr_Cntl 
line which causes power switching circuit 105 to turn 
off the appropriate power MOSFETs, thereby remov- 
ing power from PCMCIA socket 107. 

In some embodiments, PC card 110 is a mass 
storage or network device, and PROM 106 is config- 
ured to boot host computer 100 using boot images 
stored in or retrieved over a network connection by 
PC card 110. PROM 1 06 also contains a separate CIS 
interpreter for identifying tuples which provide device 
identification and configuration information for PC 
cards, e.g., card 110, during booting. The PROM res- 
ident CIS interpreter then builds a device information 
tree with at least one device information node for 
each PC card, e.g., PC card 110. In addition, PROM 
1 06 contains information defining the capabilities and 
system resources of adapter 100. For more informa- 
tion on auto-boot process, see U.S. patent applica- 
tion, Serial No. 07/842,007, entitled "METHOD AND 
APPARATUS FOR BOOTING A COMPUTER SYS- 
TEM", filed February 25, 1992, incorporated herein 
by reference in its entirety. 

In another embodiment, a 5 volt to 12 volt DC-DC 
converter 1 07 provides the higher voltage required by 
some PC cards for operation, thereby further increas- 
ing the versatility of adapter 1 00. As such, after power 
is provided to card 110, adapter 100 reads the card in- 
formation structure (CIS) located in the attribute 
memory space of card 110, to obtain information 


about PC card 110, thereby ensuring that PC card 110 
is of the type that adapter 100 is able to support In 
yet another embodiment, a test port provides internal 
diagnostics for adapter 1 00. 

5 The PCMCIA specification Version 2.1 does not 

support direct memory access (DMA) type opera- 
tions, arid hence data transfers between host com- 
puter 10 and PC card 110 are essentially programmed 
I/O type operations. However, should a later version 

10 of the PCMCIA specification support DMA, one skil- 
led in the art will be able to add DMA capability to 
adapter 100 and make the appropriate modifications 
to software driver 34, enabling host computer 10 to 
initiate data transfers between host memory 30 and 

15 PC card 110 independent of host CPU 20 after an ini- 
tial setup. 

While the invention has been described using 
specific embodiments, other embodiments, alterna- 
tives and modifications will be apparent to those ski I- 

20 led in the art without deviating from the scope and 
spirit of the invention. For example, the PCMCIA in- 
terface of the present invention may be implemented 
in varying proportions of hardware and software. 
Hence, the above description is merely illustrative 

25 and not intended to be limiting. The true scope of the 
invention is indicated by the following claims. 


Claims 

30 

1. A PCMCIA interface for providing communica- 
tions between a user application running on a 
host computer and a PC card, said interface com- 
prising: 

35 a hardware-independent nexus for proc- 

essing an external PCMCIA access request from 
said user application and generating a corre- 
sponding internal PCMCIA access request; 

a hardware-dependent driver coupled to 

40 said hardware-independent nexus for processing 
said internal PCMCIA access request and for 
causing a corresponding system bus signal to be 
generated on said system bus; and 

a PCMCIA adapter coupled between said 

45 system bus and said PC card for converting said 

system bus signal into a PC card signal for said 
PC card. 

2. The PCMCIA interface of claim 1 wherein said ex- 
50 ternal PCMCIA access request is a PCMCIA card 

service request and said hardware- independent 
nexus includes a Card Services provider for proc- 
essing said PCMCIA card service request. 

55 3. The PCMCIA interface of claim 2 wherein said 
hardware-independent nexus further includes a 
PCMCIA nexus driver coupled to said Card Ser- 
vices provider for converting said card service re- 
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quest into said internal PCMCIA access request 
for said hardware-dependent driver. 

4. The PCMCIA interface of claim 3 wherein said 
hardware-independent nexus further includes an 
events manager coupled to said PCMCIA nexus 
driver for providing a communication channel be- 
tween said PC card and said user application 
enabling said PC card to generate an unsolicited 
event report to said user application. 

5. The PCMCIA interface of claim 1 wherein said 
hardware-dependent driver includes an adapter 
driver for converting said internal PCMCIA ac- 
cess request into a system bus signal for said PC 
card. 

6. The PCMCIA interface of claim 2 wherein said 
Card Services provider includes an interpreter for 
parsing an information tuple from said PC card. 

7. The PCMCIA interface of claim 1 wherein said 
host computer is a SPARC based computer sys- 
tem. 

8. The PCMCIA interface of claim 1 wherein said 
system bus is a SPARC based SBus. 

9. The PCMCIA interface of claim 1 wherein said 
host computer is a UNIX based computer system. 

10. A method of providing communications between 
a user application running on a host computer 
and a PC card coupled to a system bus of said 
host computer, said method comprising the com- 
puter implemented steps of: 

processing said external PCMCIA access 
request; 

generating an internal PCMCIA access re- 
quest in response to said external PCMCIA ac- 
cess request; 

processing said internal PCMCIA access 
request; 

generating a system bus signal on said 
system bus in response to said internal PCMCIA 
access request; and 

converting said system bus signal into a 
PC card signal in response to said system bus 
signal. 

1 1 . The method of claim 1 0 wherein the step of proc- 
essing said external access request includes the 
step of providing PCMCIA card services. 

12. The method of claim 10 further comprising the 
computer implemented step of providing a com- 
munication channel for said PC card to generate 
an unsolicited event report to said user applica- 


tion. 

13. The method of claim 10 further comprising the 
computer implemented step of parsing an infor- 

5 mation tuple from said PC card. 

14. The method of claim 10 wherein the step of con- 
verting said system bus signal includes the step 
of converting an SBus signal. 

10 

15. A PCMCIA adapter for interfacing between an 
SBus of a host computer and a PC card, compris- 
ing: 

a PCMCIA socket for accommodating said 
15 PC card; 

a buffer for storing information to be trans- 
ferred between said SBus and said PCMCIA 
card; and 

a core logic for controlling a transfer of 
20 said information. 

16. The PCMCIAadapter of claim 15furthercompris- 
ing a switch for applying and removing power be- 
tween said SBus and said PCMCIA socket 

1 7. The PCMCIA adapter of claim 1 5 further compris- 
ing a DC-DC voltage supply coupled to said 
PCMCIA socket 

30 18. The PCMCIAadapterof claim 15 further compris- 
ing a boot PROM for booting said host computer 
with a boot image retrieved from said PC card. 
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